사실 이 부분을 고려를 할지 말지 고민을 많이 했었습니다.

레이어를 생각했을 때는 고려를 하지 않아도 된다고 생각했지만, 범용성을 고려했을 때 필요하다고 생각했습니다.

구현 후에 조금 더 고민을 해보니, 약간의 문제가 있습니다.
모바일 사용자가 SSR 환경에 접근한 경우, hydration 과정이 끝난 후에,
useEffect로 마운트된 후에 getDevice를 호출하지 않는다면, isMobile은 계속 false로 남아있습니다.

// 예시
export const useDevice = (): DeviceInfo => {
  // 예시로 useState을 사용했습니다. 
  // const { isMobile } = deviceUtil.getDevice(); 원래는 이런 방식으로 사용하는 것을 생각했습니다.  
  const [deviceInfo, setDeviceInfo] = useState<DeviceInfo>(getDevice());

  // 클라이언트에서 마운트된 후에만 실제 디바이스 정보로 업데이트
  // 이 과정이 없다면, SSR 환경에서는 isMobile이 계속 false인 상태로 남아있을 듯 합니다. 
  useEffect(() => {
    setDeviceInfo(getDevice());
  }, []);

  return deviceInfo;
};

그래서 다시 생각을 해보니, SSR 상황을 배제하고 클라이언트 상황만을 적용하는게 좋을 것 같다고 생각하는데
어떻게 생각하시나요..??

어려운데,, 재밌네요ㅎㅎ

@klmhyeonwoo

음 저도 동의합니다! 저희는 유틸 함수 라이브러리를 만들기에 window 객체를 파악하지 못하는 SSR 상황까지 커버하기에는 조금 힘들 수 있을 것 같다는 생각이 들어요!

넵!! 그러면 해당 예외처리는 제거하겠습니다..!!

음 저도 동의합니다! 저희는 유틸 함수 라이브러리를 만들기에 window 객체를 파악하지 못하는 SSR 상황까지 커버하기에는 조금 힘들 수 있을 것 같다는 생각이 들어요!